To check a software work (e.g., program, routine, procedure, application or the like) the developers have to decide what needs to be tested and how. Traditionally, the developers generate unit tests for checking all the functions of the software. However, it is not realistic to consider that all the functions of the software will be tested with all the possible inputs. In the same way, when a software is written with an object oriented language, it is impossible to test all the methods of a class for all possible inputs. Thus, the developers try to design tests that highlight bugs in their software.
To help developers to write tests, software companies have created tools to automate the generation of tests. There are two interests in using these tools, they save time and induce reliability. However, in order to make these tests more efficient, there is a need to improve the logic behind the generation of test. The tests are automatically generated by these tools according to a logic which can be that the functions are systematically tested one after one with simple values such as 0 or null pointer as parameters. Other logics test functions in a random order or in the order they appear in the source code, or according to a source coverage, or according to a record of a previous execution of a function for a replay. So, one example is to create calls of all the methods of a class in the order they appear in the source code; calls to all the methods in a random order; calls to setter fields methods then the getters; etc. The input are taken either at random or in an set of values that are expected to be critical: null pointer, null integer value, negative or positive value, empty string, etc . . . .
In the U.S. Pat. No. 5,708,774 the tests are automatically created for detecting errors in the successive levels of calls of functions in which are given parameters. If the test is positive (e.g. no exception thrown or no bad assertion risen), the result of a first test is used to create the next test: these tests are not relevant because the scenario does not respect the business logic of the application. If a test is done on accordance with the semantic of the application, an execution error, for instance could be a good behavior for a test.
Ideally, to be more efficient, test generation should follow a scenario adapted to the business logic of the application operating that software. The difficulty to generate relevant tests is that the nature of the test is closely related to the semantic of the application under test. Unfortunately, it is quite impossible to create test generators which can adapt to the semantic of the application. The test tools cannot discover this semantic and the generated tests are far from the test that would be performed by the programmer who has the knowledge of the semantic of the application under test. For example, in an application managing bank accounts, a class Account is written with methods deposit( . . . ), withDraw( . . . ), getBalance( ) and getMaxDeficitAllowed( ), it would be particularly relevant to check that one cannot withdraw an amount X if X is greater than getBalance( ) unless this amount is less than getMaxDeficitAllowed( )+getBalance( ).
However to improve test efficiency, there is a need for a method to create test generators which can be used to test an application independently from its particular semantic but with a test scenario which is close to the logic of the programming of the application.